1. Field of the Invention
This invention relates to data communications and in particular to communications switching architectures and features.
2. Description of the Related Art
Cable television operators have typically been faced with telecommunications service solutions and architectures that were developed for other industries, classes of providers, scales, and physical plants. To date, two methods of providing voice services in the multimedia-rich cable industry have been proposed and are being tested: circuit switching and distributed telephony systems. Neither is well-suited to the need to carry a wide range of multimedia (video, audio, text, graphic, wideband, and narrowband) traffic over the limited geographic scale of the typical cable television outside plant, including but not limited to the types of hybrid fiber/coaxial cable (HFC) plants seen in the field today.
Circuit switching systems have been the standard switching means for primary voice quality and reliability in public telephony networks for many years. In such a system, circuit traffic is defined as having a pre-provisioned connection through a network. In particular, TDM-based circuit traffic is defined as having reserved bandwidth through the network, and more specifically, specific time slots through the network reserved to carry the traffic for that circuit whether or not any valid traffic is available to be sent. Certain standard TDM circuit formats have been defined such as DS0, DS1, and E1. Traditional methods for connecting TDM circuits together to complete a connection employ the use of a TDM-based switch. There are various architectures and ways to construct such a switch known in the art, but a general characteristic of such a switch is that once a connection is setup, there is no competition for switching resources, so a fixed latency through the switch is guaranteed. These switches cannot handle packet traffic.
In a distributed telephony system, such as that proposed by Cable Labs and others in the PacketCable™ initiative (see below), telephony data is converted to packets and switched in a managed Internet Protocol (IP) environment, using a variety of IP and network protocols. The switch used in these types of systems, and for IP traffic in general, is typically referred to as a packet switch.
A packet switch is designed to handle packet traffic, which has different characteristics from circuit traffic. In particular, most packet systems are designed as connectionless, meaning they do not pre-provision a connection through the network, nor do they reserve bandwidth to carry the traffic. Some packet systems (for example, Asynchronous Transfer Mode [ATM] systems) do use connection-oriented protocols and some IP protocols (e.g., Multi-protocol Packet Label Switching [MPLS]) also provide a certain level of bandwidth reservation. However, these systems add extra complexity and potential compatibility issues.
In a packet switch, headers are attached to each individual packet to indicate the destination of the packet. The packets are switched in real-time to the correct output at each packet switch along the path. As a result, traffic arriving at a packet switch is non-deterministic and has to compete for switching resources as it tries to get through the switch. The resulting effect is that the packets are subject to a non-deterministic latency through the switch.
An additional characteristic of a packet switch is that it must be designed to handle different size packets. This is a result of the various protocols that are used in packet networks.
Typically, packets that are larger than the fixed size data units (FSDU) are chopped into smaller pieces (i.e., fragmented or segmented). Packets that are smaller than the FSDU are padded to make a full FSDU. The size of the FSDU is arbitrary, although it is generally optimized to be efficient for the range of packet sizes expected in the application for which it is designed. An FSDU for a typical packet switch is between 64 bytes and 256 bytes.
As networks merge in the current telecommunication world, systems are being designed to accommodate both TDM circuit traffic and packet traffic simultaneously. The most cost-efficient implementation of such a system uses a single switch fabric to accommodate both pure data packet and packetized voice (e.g., VoIP) traffic. Such a system needs to consider the various requirements of these two inherently different types of traffic.
Voice over Internet Protocol (VoIP) networks 100 use the architectural framework shown in FIG. 1 to route packetized voice conversations via the Real Time Protocol (RTP) described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 1889 between endpoints or Multimedia Terminal Adapters (MTAs) 101. MTAs convert voice into RTP packets 105 in one direction and RTP packets into voice in the other direction. A Public Switched Telephone Network 150 (PSTN) Gateway 110 is used when the call's destination is to a telephone 115 located on the PSTN. A Call Management Server (CMS) 120 uses an industry-standard signaling (SIG) protocol 125 such as H.323, SIP, MGCP, or MEGACO to set up the RTP flow between these endpoints. This traditional VoIP network architectural framework optimizes the use of network bandwidth but is inadequate for carrier class telephony where user privacy, operator busy line verification and break in, and the Communications Assistance for Law Enforcement Act (CALEA) are required.
MTAs have telephone functions built in or provide an RJ-11 or other industry-standard interface to a standard telephone set connection 130. In either case, MTAs are provided as Customer Premises Equipment (CPE) located within a subscriber's residence or business. A MTA can therefore be tampered with or replaced with non-standard equipment capable of monitoring IP traffic the network and providing proprietary information to an unauthorized user. With this information a malicious user could originate network signaling and/or control packets that could interrupt or deny service to other users on the network. Such disruptions (sometimes referred to in the data communications arts as a “Denial of Service” or DoS Attack) are unacceptable when a VoIP network is used for primary line telephone service. Furthermore, since the IP address of a subscriber's MTA is the routing equivalent of their phone number, regulations that require the subscriber's ability to block the well-known Caller ID service/function could be interpreted to also require blocking of their IP address in a VoIP deployment. Theft of services is also a recognized risk to be avoided. Protection of CPE and CPE-based functionality must also take into account the need for content and service security.
In addition, the Communications Assistance for Law Enforcement Act (CALEA) requires that a service provider support lawful surveillance of traffic in the network unobtrusively delivering the call identifying information and/or its content. With the traditional VoIP architectural framework described above, CALEA is very complex and may require the coordination of multiple network elements. (Such an alternative is described in, for example, the PacketCable Electronic Surveillance Specification PKT-SP-ESP-i01-991229, which is incorporated herein by reference in its entirety.) Other architectural features, requirements, and industry standards relating to providing VoIP and other secure media services over the cable television network infrastructure can be found in the various Packet Cable specifications and reports provided at                http://www.packetcable.com/specifications.html        
The names and numbers of these specifications are reproduced in the following tables. These specifications are incorporated herein by reference in their entireties for their descriptive and reference material on the state of the art in VoIP over cable.
Note that Engineering Change Notices (ECNs) have been approved for several of the PacketCable interim specifications and these ECNs are considered part of the PacketCable specifications. ECNs are posted to the PacketCable LiveLink site (see the hyperlink above).
PacketCable 1.0
The eleven specifications and six technical reports in the following table define PacketCable 1.0. Together these documents define the call signaling, Quality of Service (QoS), CODEC, client provisioning, billing event message collection, PSTN (Public Switched Telephone Network) interconnection, and security interfaces necessary to implement a single-zone PacketCable solution for residential Internet Protocol (IP) voice services. “Single-zone” here refers to a system serving a single HFC cable plant or region.
SpecificationPacketCable 1.0 Specifications & Technical ReportsNumberPacketCable ™ Audio/Video CODEC SpecificationPKT-SP-CODEC-I03-011221PacketCable ™ Dynamic Quality-of-ServicePKT-SP-DQOS-SpecificationI03-020116PacketCable ™ Network-Based Call SignalingPKT-SP-EC-Protocol SpecificationMGCP-I04-011221PacketCable ™ Event Message SpecificationPKT-EM-I03-011221PacketCable ™ Internet Signaling TransportPKT-SP-ISTP-Protocol (ISTP) SpecificationI02-011221PacketCable ™ MIBs Framework SpecificationPKT-SP-MIBS-I03-020116PacketCable ™ MTA MIB SpecificationPKT-SP-MIB-MTA-I03-020116PacketCable ™ Signaling MIB SpecificationPKT-SP-MIB-SIG-I03-011221PacketCable ™ MTA Device ProvisioningPKT-SP-PROV-SpecificationI03-011221PacketCable ™ Security SpecificationPKT-SP-SEC-I05-020116PacketCable ™ PSTN Gateway Call SignalingPKT-SP-TGCP-Protocol SpecificationI02-011221PacketCable ™ NCS Basic Packages TechnicalPKT-TR-MGCP-ReportPKG-V01-020315PacketCable ™ Architecture Call FlowsPKT-TR-CF-ON-Technical ReportON-V01-991201On-Net MTA to On-Net MTAPacketCable ™ Architecture Call FlowsPKT-TR-CF-ON-Technical ReportPSTN-V01-991201On-Net MTA to PSTN TelephonePacketCable ™ Architecture Call FlowsPKT-TR-CF-PSTN-Technical ReportON-V01-991201PSTN Telephone to On-Net MTAPacketCable ™ 1.0 Architecture FrameworkPKT-TR-ARCH-Technical ReportV01-991201PackctCable ™ OSS Overview Technical ReportPKT-TR-OSS-V02-991201PacketCable 1.1
The five specifications and four technical reports in the following table define requirements for offering a Primary Line-capable service using the PacketCable architecture. The designation of a communications service as “primary” means that the service is sufficiently reliable to meet an assumed consumer expectation of essentially constant availability. This also includes, specifically, availability during power failure at the customer's premises and (assuming the service is used to connect to the PSTN) access to emergency services (E911, etc.).
SpecificationPacketCable 1.1 Specifications & Technical ReportsNumberPacketCable ™ Management Event MIBPKT-SP-EVEMIB-SpecificationI01-020315PacketCable ™ Embedded MTA Primary LinePKT-SP-EMTA-Support SpecificationPRIMARY-I01-001128PacketCable ™ Management Event MechanismPKT-SP-MEM-I01-001128PacketCable ™ Electronic SurveillancePKT-SP-ESP-I01-Specification991229PacketCable ™ Audio Server ProtocolPKT-SP-ASP-102-Specification010620PacketCable ™ Line Control Signaling SystemPKT-TR-ARCH-Architecture Technical ReportLCS-V01-010730PacketCable ™ Management Event IdentifiersPKT-TR-Technical ReportMEMEVENT-ID-V01-001128VoIP Availability and Reliability Model for thePKT-TR-VOIPAR-PacketCable ™ Architecture Technical ReportV01-001128PacketCable ™ Electronic Surveillance Call FlowsPKT-TR-ESCF-Technical ReportV01-991229PacketCable 1.2
The two specifications and one technical report in the following table define the functional components and interfaces necessary to allow communication between PacketCable 1.0 networks using an IP transport or backbone network. These specifications describe the call signaling and Quality of Service (QoS) extensions to the PacketCable 1.0 architecture to enable cable operators to directly exchange session traffic. This will allow a subscriber on one PacketCable network to establish end-to-end IP or “on-net” sessions with subscribers on other PacketCable networks. For PacketCable, “on-net” means that the call is established end-to-end on the IP network without traversing the PSTN network at any time.
SpecificationPacketCable 1.2 Specifications & Technical ReportsNumberPacketCable ™ Call Management Server SignalingPKT-SP-CMSS-I01-Specification001128PacketCable ™ Interdomain Quality of ServicePKT-SP-IQOS-I01-Specification001128PacketCable ™ 1.2 Architecture FrameworkPKT-TR-ARCH1.2-Technical ReportV01-001229
What is needed is a secure media processing and switching system that is compatible with the PacketCable specifications (so that it can serve cable systems) and is resistant to theft and Denial of Service attacks while supporting CALEA, E911, and toll quality of service requirements. This system must interface with existing PSTN gateway systems, cable headend, and HFC plant equipment. Furthermore, such a system must be integrated under a single EMS, fault-resilient, robust, scaleable, and ultimately cost effective in order to overcome the known shortcomings in the present state of the art.